CLIでAmazon Workspacesを作成する場合の注意事項
しばたです。
本記事は正確には「WorkSpacesとディレクトリを紐づける際の注意事項」なのですが分かりやすさのためにこんなタイトルにしています。
ちょっと今CLI(AWS Tools for PowerShell)でAD ConnectorおよびWorkSpaces作っていたのですが、その際に何点かハマった点があったのでこの記事で共有します。
使っていたのがAWS Tools for PowerShellだったので記事中もPowerShellのコード例を出しますがAWS CLIを使う場合でも同様の注意が必要となります。
AWS CLIをお使いの方は適宜コード例を置き換えてみてください。
WorkSpacesとディレクトリを紐づける際の権限について
CLIでWorkSpacesとディレクトリを紐づけるにはRegister-WKSWorkspaceDirectoryコマンドレット(AWS CLIの場合はaws workspaces register-workspace-directory)を使い以下の様に実行します。
$params = @{
DirectoryId = '<紐づけ対象のディレクトリID>'
SubnetId = ('<WorkSpacesを展開するサブネットID 1つめ>', 'WorkSpacesを展開するサブネットID 2つめ')
EnableSelfService = $true
EnableWorkDoc = $false
}
Register-WKSWorkspaceDirectory @params
当然このコマンドの実行にはそれなりの権限が求められ、権限不足の場合は下図の様なエラーとなります。
ここでは
User <your role> is not authorized to perform: workspaces:RegisterWorkspaceDirectory on resource: arn:aws:workspaces:ap-northe
ast-1:xxxxxxxxx:/
とworkspaces:RegisterWorkspaceDirectoryという見慣れない権限を求められます。
この権限はマネジメントコンソールから追加しようとしても「そんな権限は無い」と警告されるうえに、
強引に設定しても結局権限エラーのまま別のメッセージが表示されてしまいます。
Register-WKSWorkspaceDirectory : You do not have sufficient access to perform this action. For more information, see https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-access-control.html.
WorkSpacesの管理に関わる権限はこちらで紹介されている
に詳細が記載されており、この内容に従う必要があります。
例えばWorkSpacesの管理に関わる全権が必要な場合は
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"workspaces:*",
"ds:*",
"iam:PassRole",
"iam:GetRole",
"iam:CreateRole",
"iam:PutRolePolicy",
"kms:ListAliases",
"kms:ListKeys",
"ec2:CreateVpc",
"ec2:CreateSubnet",
"ec2:CreateNetworkInterface",
"ec2:CreateInternetGateway",
"ec2:CreateRouteTable",
"ec2:CreateRoute",
"ec2:CreateTags",
"ec2:CreateSecurityGroup",
"ec2:DescribeInternetGateways",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:AttachInternetGateway",
"ec2:AssociateRouteTable",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DeleteSecurityGroup",
"ec2:DeleteNetworkInterface",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"workdocs:RegisterDirectory",
"workdocs:DeregisterDirectory",
"workdocs:AddUserToGroup"
],
"Resource": "*"
}
]
}
が必要とされており、結局workspaces:*、ds:*な権限が必要となります。
workspaces_DefaultRole IAMロールの事前準備について
必要な権限を設定し再度Register-WKSWorkspaceDirectoryを実行しても今度は以下の様に「workspaces_DefaultRole IAMロールが無い」と怒られてしまいます。
このworkspaces_DefaultRoleロールはWorkSpacesのサービスにデフォルトで設定されるロールであり、マネジメントコンソールから手作業で紐づけ作業を行う場合は裏側で自動作成されるロールになります。
CLIから紐づけを行う場合は事前に作成しておく必要があります。
workspaces_DefaultRoleロールの作り方についても先ほどのドキュメントに記載されています。
詳細についてはドキュメントをご覧いただきたいのですが、大事な点としては
- WorkSpacesのサービスが利用する権限のため、信頼されたエンティティを「
workspaces.amazon.com」とする AmazonWorkSpacesServiceAccess、AmazonWorkSpacesSelfServiceAccessの2つのマネージドポリシーをアタッチする
になります。
参考としてPowerShellから作る手順を紹介しておきます。
# まずはロールを作成
$params = @{
RoleName = 'workspaces_DefaultRole'
Description = 'WorkSpaces default role created by user. (not by console!)'
AssumeRolePolicyDocument =
@'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "workspaces.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
'@
}
$role = New-IAMRole @params
# 2つのマネージドポリシーをアタッチ
Register-IAMRolePolicy -RoleName $role.RoleName -PolicyArn 'arn:aws:iam::aws:policy/AmazonWorkSpacesServiceAccess'
Register-IAMRolePolicy -RoleName $role.RoleName -PolicyArn 'arn:aws:iam::aws:policy/AmazonWorkSpacesSelfServiceAccess'
補足 : ロール作成権限に関して
workspaces_DefaultRoleロールを作成するにはiam:CreateRoleとiam:AttachRolePolicyが必要になりますが、先述のドキュメントにはiam:AttachRolePolicyに対する記述はありませんので、必要に応じて適宜権限を与えておく必要があります。
マネジメントコンソールから workspaces_DefaultRole を作る場合との微妙な差異
最後にworkspaces_DefaultRoleロールについて、ドキュメントで要求されるロールとマネジメントコンソールから自動作成された場合で微妙に権限が異なるのでその差異について紹介しておきます。
ドキュメントが要求する権限
まずはドキュメントが要求するAmazonWorkSpacesServiceAccess、AmazonWorkSpacesSelfServiceAccessの2つのマネージドポリシーの権限は以下の通りとなっています。
AmazonWorkSpacesServiceAccess
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
AmazonWorkSpacesSelfServiceAccess
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"workspaces:RebootWorkspaces",
"workspaces:RebuildWorkspaces",
"workspaces:ModifyWorkspaceProperties"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
マネジメントコンソールから自動生成される権限
次にマネジメントコンソールから自動生成された場合ですが、
上図の様にマネージドポリシーではなく
- SkyLightServiceAccess
- SkyLightSelfServiceAccess
の2つのインラインポリシーがアタッチされています。
これらの権限は以下の通りです。
SkyLightServiceAccess
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"galaxy:DescribeDomains"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
SkyLightSelfServiceAccess
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"workspaces:RebootWorkspaces",
"workspaces:RebuildWorkspaces",
"workspaces:ModifyWorkspaceProperties"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
両者の差異
両者を比較するとこの様になります。
| ドキュメントが要求するポリシー | マネジメントコンソールから自動生成されるポリシー | 差異 |
|---|---|---|
| AmazonWorkSpacesServiceAccess | SkyLightServiceAccess | SkyLightServiceAccess のみ galaxy:DescribeDomains が存在 |
| AmazonWorkSpacesSelfServiceAccess | SkyLightSelfServiceAccess | 差異なし |
内容はほぼ同一ですが、SkyLightServiceAccessにのみgalaxy:DescribeDomainsという謎のアクションを許可する設定が組み込まれています。
そもそもgalaxy:というサービスが何なのかは完全に謎ですが一般ユーザーが気にする類のものではないと思われますのでどちらを選んでも問題ないでしょう。
ただ「作り方により差異がある」点は知っておくとトラブルシュート等の場合で役に立つこともあるかと思います。
終わりに
以上となります。
CLIからWorkSpaces環境を構築すること自体がレアケースかもしれませんが、この記事の内容がこれからCLIを試してみる方の役に立てば幸いです。
